home *** CD-ROM | disk | FTP | other *** search
-
-
- Network Working Group P. Francis
- INTERNET-DRAFT (formerly P. Tsuchiya)
- Bellcore
- June 1993
-
-
- Pip Identifiers
-
-
- Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts).
-
- Internet Drafts are draft documents valid for a maximum of six
- months. Internet Drafts may be updated, replaced, or obsoleted by
- other documents at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other than as a "working
- draft" or "work in progress."
-
- Please check the I-D abstract listing contained in each Internet
- Draft directory to learn the current status of this or any other
- Internet Draft.
-
-
- Abstract
-
- Pip is an internet protocol intended as the replacement for IP
- version 4. The Pip header defines source and destination ID fields
- whose primary function it is to identify the source and destination
- of a Pip packet. While Pip systems treat the IDs as flat for the
- purpose of identification, it is useful to have hierarchical
- structure in the ID for other purposes, such as for doing a reverse
- DNS lookup on the ID. This internet-draft defines the structure of
- Pip IDs.
-
-
-
- 1. Changes From Previous Version
-
- The previous version is dated January 1993. Following is a summary
- of changes from that version.
-
-
-
-
- Pip WG, Expires December 1, 1993 [Page 1]
-
-
-
-
-
-
- INTERNET-DRAFT Pip Identifiers June 1993
-
-
- 1. A code point was added for "local" IP address. This is an IP
- address that is not guaranteed to be globally unique. With this
- code-point, a system can assign itself an ID based on its IP
- address, but the ID will only be unique within the systems "IP-
- unique" domain. As long as all IP addresses are unique, the ID
- will also be unique.
-
- 2. A section describing Pip ID notation was added.
-
- 3. The ASN.1 style of assignment was removed. This results in the
- Pip ID hierarchy not being self describing. This is the result
- of a general notion that Pip IDs should largely be considered
- flat entities, and in particular that Pip systems should use an
- Ethernet number to derive their Pip IDs. Because the ASN.1
- style of assignment was removed, all of the previous assignments
- are different.
-
-
-
-
- 2. Introduction
-
- Pip is an internet protocol intended as the replacement for IP ver-
- sion 4. The Pip header defines source and destination ID fields
- whose function, in the context of host processing of Pip headers, is
- to only identify the source and destination of a Pip packet. While
- Pip systems treat the IDs as flat for the purpose of identification,
- it is useful to have hierarchical structure in the ID for other pur-
- poses, such as for doing a reverse DNS lookup on the ID. This
- internet-draft defines the structure of Pip IDs.
-
- Pip IDs have the following characteristics:
-
- 1. With well-known exceptions, they are globally unique binary
- strings 8 octets in length.
-
- 2. While they are hierarchically structured for assignment pur-
- poses, the Pip layer does not treat them as hierarchical.
- Further, assignments are set aside for such addresses as IEEE
- 802, resulting in what is effectively a flat ID.
-
- 3. Each component of the hierarchy is contiguous, and each
- hierarchical component is positioned in the Pip ID adjacent to
- its parent and child components.
-
-
-
-
- Pip WG, Expires December 1, 1993 [Page 2]
-
-
-
-
-
-
- INTERNET-DRAFT Pip Identifiers June 1993
-
-
- 4. Each level of the hierarchy can fall on an arbitrary bit boun-
- dary.
-
- 5. Pip IDs may be used for group identification, but such a Pip ID
- is not self-describing as being a group Pip ID.
-
- 6. Certain Pip IDs are well-known and have local meaning, such as
- "all routers on the subnet" and "this host".
-
- Pip IDs are formed by a hierarchy of number authorities, each of
- which is responsible for assigning the next lower level of the
- hierarchy. Generally it is the intent that Pip IDs be treated as
- flat, and that the hierarchy is solely for the purposes of insuring
- uniqueness. In particular, it is not assumed that an inverse DNS
- lookup on the Pip ID works.
-
- To the extent that the hierarchy in a Pip ID is exploited for other
- purposes, it is recommended that the hierarchical structure of Pip
- IDs follow administrative hierarchy (versus, for instance, topologi-
- cal hierarchy). It is up to each number authority to determine how
- the next level is assigned.
-
- I should be noted that some people are of the opinion that Pip IDs
- (or, network layer IDs in general) should have organizational
- hierarchical content that might be used for accounting of various
- kinds, inverse DNS lookups, and perhaps other things. Bob Smart and
- John Curran in particular have put forth arguments to this effect,
- and were acknowledged in the first draft of this document, which
- embraced their philosophy. Since then, I have become concerned that
- this placed too many constraints on Pip IDs, in particular with
- regards to auto-configuration of hosts, and the need to change Pip
- IDs when a host changes organizations. However, the issues of organ-
- izationally meaningful Pip IDs versus flat Pip IDs is still an open
- one. This specification does not prohibit the creation of organiza-
- tionally meaningful Pip IDs, should that be found useful by various
- organizations or across the board.
-
-
-
- 3. Pip ID Notation
-
- This section describes a uniform method to write Pip IDs. This
- method should be used whenever Pip IDs are written or typed. In par-
- ticular, all software used to read or write Pip IDs should use this
- notation.
-
-
-
- Pip WG, Expires December 1, 1993 [Page 3]
-
-
-
-
-
-
- INTERNET-DRAFT Pip Identifiers June 1993
-
-
- A Pip ID is written as a sequence of 8 2-digit hex numbers separated
- by dots. Leading 0's are written.
-
-
-
- 4. Assigned Top-level Pip ID Numbers
-
- The top-level assignment authority (as yet unspecified, but IANA, the
- Internet Assigned Numbers Authority, seems to be a logical candidate)
- is responsible for assigning prefixes (the most significant bits) of
- the Pip ID. By assigning a prefix, the top-level authority creates a
- block of addresses, the authority of which is handed to another
- organization.
-
- The following Pip ID assignments are defined:
-
-
-
- 4.1. CCITT E.164
-
- A CCITT E.164 address can be used to create a globally unique Pip ID.
- Thus, anybody with an E.164 address can use it to form a globally
- unique Pip ID. All Pip IDs formed from E.164 address have the form:
-
- | 14-bit prefix |---50 bits---|
- |00000000 000000| E164Address |
-
- That is, 14 bits of value 0, followed by the E.164 address, converted
- to binary (note this is not BCD encoding, but strict binary). 50
- bits is adequate to encode all E.164 addresses in binary.
-
-
-
- 4.2. IEEE 802 Address
-
- An IEEE 802 address can be used to create a globally unique Pip ID.
- Thus, anybody with an IEEE 802 address can use it to form a globally
- unique Pip ID. All IEEE 802 based Pip IDs have the format:
-
- (hex) 80.00.IEEE802address
-
- That is, the first 16 bits are (hex) 8000, followed by the 48 bit
- IEEE 802 Address. Thus, the valid range of IEEE 802 based Pip IDs
- is:
-
-
-
-
- Pip WG, Expires December 1, 1993 [Page 4]
-
-
-
-
-
-
- INTERNET-DRAFT Pip Identifiers June 1993
-
-
- 80.00.00.00.00.00.00.00 to 80.00.ff.ff.ff.ff.ff.ff.
-
-
-
- 4.2.1. Locally Unique ID
-
- If a host has no IEEE 802 address, it can create a locally unique
- (local to the subnet) Pip ID using the IEEE 802 prefix. To do this,
- the local subnet address is placed in the low order part of the Pip
- ID, and the remaining bits of the 48-bit space are filled in ran-
- domly.
-
-
-
- 4.3. Local IP Domain
-
- A Pip ID can be formed from an IP address. As long as IP addresses
- are globally unique, a Pip ID formed from an IP address is also glo-
- bally unique. All IP Address based Pip IDs have the format:
-
- (hex) 40.00.00.00.IPaddress
-
- That is, the first 32 bits are 40.00.00.00, followed by a 32-bit IP
- Address. Thus, the valid range of IP based Pip IDs is:
-
- 40.00.00.00.00.00.00.00 to 40.00.00.00.ff.ff.ff.ff.
-
-
-
- 4.4. Flat Well-Known IDs
-
- There are any number of uses for identifying systems of a certain
- type, rather than specific systems. For instance, an ID for "all
- routers on the LAN" is useful for router discovery. This specifica-
- tion defines the following well-known Pip IDs. These well-known Pip
- IDs consist of a single hierarchy level (the top-level), but are so
- large that only one level of hierarchy is possible.
-
- Any Router = ff.ff.ff.ff.ff.ff.ff.fe
-
- Any Host = ff.ff.ff.ff.ff.ff.ff.fd
-
- Any System = ff.ff.ff.ff.ff.ff.ff.fc
-
- The above three well-known Pip IDs serve for functions such as "all
-
-
-
- Pip WG, Expires December 1, 1993 [Page 5]
-
-
-
-
-
-
- INTERNET-DRAFT Pip Identifiers June 1993
-
-
- routers on a subnet", for instance in configuration algorithms such
- as router discovery. Other well-known Pip IDs are expected to be
- defined in the future.
-
-
-
- 4.5. Country Codes
-
- While it is expected that most hosts will obtain their Pip ID from an
- IEEE802 address (either from their interface card from from their
- CPU), it may be necessary to obtains IDs from other sources. For
- this purpose, a 32-bit block of IDs have been assigned to each coun-
- try. The countries can further assign blocks to organizations if
- desired. It should be noted that Pip systems with an assignment from
- a country's block is in no way constrained to reside in that country.
-
- Pip IDs formed by country code have a prefix of:
-
- |------22 bit prefix-----|--10 bits---|----32 bits---|
- |11000000 00000000 000000| ISO 3166 | remainder |
-
- ISO 3166 is the ISO standard for country codes. All country codes
- are between 0 and 999 (decimal), so 10 bits are adequate. The coun-
- try codes are encoded in binary when in the Pip ID.
-
- It is recognized that, in the long run, 32 bits per country will not
- be adequate. When countries need more code space, it can be allo-
- cated at that time. It is likely that we will have a better idea of
- ID assignment needs at that time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Pip WG, Expires December 1, 1993 [Page 6]
-
-
-